Method and Apparatus for Handling Invites to a Multi-User Communication Session

ABSTRACT

A method of handling Invite messages for a multi-user communication session utilizing the IP Multimedia Subsystem to set up and control the session. Two or more access servers control user access. A first access server receives from a session-initiating user, an Invite that identifies as a potential participant, at least one user group which is owned by a second access server. The first access server sends to the second access server, an Invite that identifies the user group. The second server resolves the group identification into a set of group member identities and sends the identities in a response to the first access server. The first access server then sends Invites to at least some of the group members identified in the response.

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for handlinginvites to a multi-user communication session. The invention isapplicable in particular, though not necessarily, to conference typesessions such as push-to-talk.

BACKGROUND TO THE INVENTION

Walkie-talkie type services have long proved popular amongst users whowish to communicate brief messages quickly between one another.Conventionally, such services have been provided by two-way portableradios which utilise a dedicated part of the radio spectrum, but whichonly allow users to communicate with a small group of pre-selected userswho utilise similar terminals and who are within range of the relativelyshort operating range of the radios. More recently, services have beenintroduced into the United States which piggy-back on the existingcellular telephone infrastructure. However, these services have beenproprietary in nature and have not allowed users to communicate betweendifferent operator networks.

In an attempt to broaden the use of walkie-talkie type services, anindustry grouping known as the Open Mobile Alliance(www.openmobilealliance.org) has been established with the aim ofstandardising suitable protocols which will allow inter-networkoperability for Warlike-Talkie services offered over cellular networks.The service established by the various standards is known as Push totalk Over cellular (PoC). PoC makes use of the IP Multimedia Subsystem(IMS) to handle the setting up and control of PoC sessions via PoCservers (acting as SIP ASs). PoC proposes that associated speech datawill be transported over a packet switched access network. In the caseof GSM and UMTS, this will be the general packet radio service (GPRS)access network. In other network architectures, analogous packetswitched access networks will be utilised for transporting talk data.Push to Talk services may also be offered over circuit switched accessnetworks, although this is not the preferred option. The current stateof PoC is set out in Release 1.0.

SUMMARY OF THE INVENTION

PoC Release 1.0 provides for a conference functionality where multipleusers may participate in a common PoC session. It is possible for eachof the participants to be associated with a different PoC server, aswould be the case where different users are registered with differentoperator networks. In such a scenario, one of the PoC servers, typicallythat associated with the initiating user, is designated to perform theControl PoC function, acting as a “conference bridge” and handling floorcontrol (i.e. allocating talk slots to participants). Other PoC serversare referred to as Participating PoC servers.

A user may establish communication with a group of other users on anad-hoc basis, i.e. the user can select from his phone book a number ofusers, press the PoC button on his terminal, and communication isestablished with all users that are available at that moment. PoC alsoallows a user to define groups of people (referred to by the OMAstandards as a “Pre-arranged PoC Group”), where the group and acorresponding PoC Group Identity is stored at the user's PoC server inthe Home Network. Once a group is defined, a user can initiate a PoCsession with the available members of the group merely by sending anINVITE containing the Group Identity.

Consider now a PoC Server receiving from a user a request to establishan Ad-hoc PoC Group Session, the request contains a list of PoC Users toinvite. For user identities (which are in the form of a UniversalResource Locator or URL) which correspond to an individual PoC User, thePoC Server can invite the PoC User without any problem using the PoCRelease 1.0 procedure. This involves forwarding the INVITE to the PoCserver identified as responsible for the destination user, where theforwarded INVITE includes the feature-tag “isfocus”. This tag identifiesthat the sending PoC server is the controller of the PoC group session.The receiving server recognises this tag and in response does notestablish itself as a controlling server. The receiving server merelyforwards the INVITE to the destination user(s) for which it isresponsible.

If the INVITE sent by the originating user contains an identity (URL)which corresponds to a PoC Group that is “owned” by the controlling PoCserver, the server will merely “explode” the group and forward theINVITE to the PoC server(s) associated with group members. If theoriginal INVITE contains a PoC Group Identity which is owned by a PoCserver other than the controlling server, the controlling server willforward the INVITE to that owning server. This is where the problembegins, as in this situation PoC Release 1.0 forces the receiving PoCserver to reject the INVITE. This feature is intended to retain controlof PoC sessions at PoC servers owning particular groups and therebyprevent the establishment of multiple controlling PoC servers for asingle PoC session.

A solution to the problem of multiple controlling PoC servers mightinvolve some negotiation of who is the controller and the chaining ofmultiple PoC servers together. However, such a solution would be complexand may result in the establishment of “infinite” loops. There is alsothe issue of deciding the state of a PoC group when a PoC Group isinvited to the Ad-hoc PoC Session. For example, if a member of thePre-arranged PoC Group (not part of the Ad-hoc PoC Session for somereason) initiates a PoC Group Session for that Pre-Arranged PoC Group,shall that member be added to the Ad-hoc PoC Group Session or shall aseparate PoC Group Session be established? Any policy for handling these“conflicts” will necessarily be complex.

A further problem which might arise in the case of PoC sessionsinvolving pre-defined groups is that of a user belonging to severalpre-defined and “nested” groups. This will result in the user receivingmultiple invites to the same session. This would be both annoying and awaste of network resources (particularly problematic where the accessnetwork is a cellular network).

It will be appreciated that problems analogous to those described abovearise in the case of other, non-PoC, IMS-based services, for exampleinstant messaging services.

According to a first aspect of the present invention there is provided amethod of handling invites to a multi-user communication sessionemploying the IP Multimedia Subsystem to setup and control the session,wherein user access is controlled by two or more user access serverswithin the IP Multimedia Subsystem, the method comprising;

-   -   receiving a session invitation at a first user access server        from a session initiating user, the invitation identifying as a        potential participant at least one user group which is owned by        a second user access server;    -   sending an invitation to the second user access server, the        invitation including an identification of said user group;    -   at said second user access server, resolving the group        identification into a set of group member identities;    -   sending a response containing said group member identities to        said first user access server; and    -   at said first user access server, sending an invitation to at        least some of the group members identified in said response.

A particular application of the present invention lies in the provisionof a push-to-talk service such as, for example, Push-to-talk overCellular (PoC). In this application, said user access servers arepush-to-talk servers, and said users are push-to-talk clients. Saidfirst user access server acts as a controlling PoC server, whilst saidsecond user access server acts as a participating PoC server and not asa controlling server. Where multiple PoC servers are contacted by thecontrolling PoC server, all of the other servers act as participatingPoC servers.

The method may comprise, at the second user access server, using apre-defined policy to authorize invitation of the identified group tothe session. Failure to authorize results in a rejection of theinvitation.

The method may comprise, at the second user access server, using apre-defined policy to authorize the requesting user to invite theidentified group to the session. The pre-defined policy may require thatthe requesting user be a member of the pre-defined group in order toproceed. Failure to authorize results in a rejection of the invitation.

The method may comprise, upon receipt of the response at the first useraccess server, sending invites to ones of the group members according toa pre-defined policy. This policy may prevent the sending of invitationsto group members which are themselves group identifications. In theevent that the policy allows the sending of invitations to group memberswhich are themselves group identifications, the policy may place a capon the number of nested group identifications which are resolved intomember identities.

According to a second aspect of the present invention there is provideda user access server for use in an IP Multimedia Subsystem, the servercomprising;

-   -   means for receiving a session invitation from a session        initiating user, the invitation identifying as a potential        participant at least one user group which is owned by a second        user access server;    -   means for sending an invitation to the second user access        server, the invitation including an identification of said user        group;    -   means for receiving from said second user access server a        response containing group member identities resolved by the        second access server from said group identification; and    -   means for sending an invitation to at least some of the group        members identified in said response.

According to a third aspect of the present invention there is provided auser access server for use in an IP Multimedia Subsystem, the servercomprising;

-   -   means for receiving from another user access server an        invitation including an identification of a user group owned by        the receiving server;    -   means for resolving the group identification into a set of group        member identities; and    -   means for sending a response containing said group member        identities to said first user access server.

BRIEF DESCRIPTION OF CERTAIN EMBODIMENTS

FIG. 1 shows a signalling flow in a PoC architecture associated with thesetting up of a PoC conference.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

A Push-to-talk over Cellular (PoC) client (Client A) initiates a PoCGroup Session using the procedure defined by OMA PoC. The PoC GroupSession can use a Pre-established Session or be On-demand. In the caseof a Pre-established Session, the PoC Client establishes a SIP sessionto its PoC Server in the Home network using an INVITE (typically whenthe PoC Client register to IMS). Once the SIP session is established thePoC Client can initiate a PoC Session using the Pre-established Sessionand the SIP REFER request. In the case of an On-demand session, the PoCClient initiates PoC Sessions without first establishing aPre-established session, using the SIP INVITE request directly.

The list of users to be invited is included in the SIP request(typically a SIP INVITE) sent to the initiator's Home PoC server. In theexample considered here, the list of PoC users to be invited consists ofa mixture of PoC Addresses (URIs) of individual PoC Users and PoC GroupIdentities of Pre-arranged PoC Groups. FIG. 1 illustrates the signallingflow associated with the PoC session establishment, assuming an Ad-hocPoC Group Session using On-demand signaling as an example. The sameprinciple applies for Ad-hoc PoC Group Session using a Pre-establishedSession signaling and Pre-Arranged PoC Group Session using On-demandsignaling or Pre-established Session signalling.

The signalling steps are as follows:

1. The PoC Client A sends a SIP INVITE request to its home PoC Serveridentified by a Conference URI (typically a “factory” setting in theclient). The SIP INVITE request contains PoC Addresses identifying PoCUsers and two PoC Group Identity identifying a Pre-Arranged group, GroupX and Group Y.

2. & 4. The PoC Server A/X1 identifies the SIP INVITE request to be theinitialization of an Ad-hoc PoC Group Session and starts to sendinvitations according to the invitation list. The invitations includethe feature-tag “isfocus” to indicate that the PoC Server A/X1 is thecontroller of the PoC Group Session to be established. The sending ofInvites to individual PoC users is represented at step 4., where theparticipating servers are shown as a single server B1-Bn.

3. One of the receivers is the PoC Server X2 which is the owner of GroupX. The PoC Server X2 (the PoC Server handling the Pre-arranged PoCGroup) detects the feature-tag “isfocus” contained in the INVITE, andperforms the following steps:

-   -   a) It checks if it is allowed according to its policy to invite        Group X to another PoC Session. The policy may be per        Pre-Arranged PoC Group or may be a general PoC service policy.        In this example it is allowed.    -   b) It then authorizes the initiator. This could be done by        checking if the inviting PoC user is a member of Group X. In        this example the PoC User is a member. This could be done using        the P-Asserted-Identity header or the From header of the        INVITE). Alternatively, authorization may be based upon a group        policy defined by the group owner (e.g. a “white” list), or on        an operator defined policy.    -   c) It returns a SIP 3xx or SIP 4xx response including the list        of members of the PoC group to the PoC server A/X1. In the        Figure, the SIP 300 “Multiple Choices” response is sent to the        PoC Server A/X1. The list of members may include both individual        PoC Users and further PoC Groups.    -   [If according to check a), the group cannot be invited to        another PoC session, the INVITE is rejected. Similarly, if        according to check b) the inviting user is not a member of the        group, the INVITE is rejected. Of course, alternative policies        for determining what action to take in such situations can be        defined.]

4. The PoC Server A/X1 receives the list and performs the following:

-   -   a) It checks its policy and decides to invite the set of PoC        Users contained in the SIP 300. It rejects any group identities        contained in the response.    -   b) It removes already invited users from the list in order to        avoid the sending of duplicate INVITEs to individual clients        (and groups).    -   c) It invites the rest of the users on the list and sends an        INVITE request to each address.

5. & 6. Another recipient of the original INVITE is the PoC server X3which is the owner of Group Y. PoC server X3 performs the same checks aswere performed by server X2 and, assuming that it accepts the INVITE,returns a SIP 300 “Multiple Choices” response includes all members ofGroup Y. Again, the list of members can include both individual PoCUsers and other PoC Groups. PoC server repeats checks a) to c) describedabove.

In this example, the controlling PoC server rejects additional groupsidentified in response messages, i.e. it performs only a single level ofGroup Identity resolution. This is done to prevent lengthy groupresolution processes and potentially infinite loop exchanges. However,some finite number of resolution levels may be permitted depending uponthe policy implemented at the controlling PoC server.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiment withoutdeparting from the scope of the present invention.

1. A method of handling invites to a multi-user communication sessionemploying the IP Multimedia Subsystem to setup and control the session,wherein user access is controlled by two or more user access serverswithin the IP Multimedia Subsystem, the method comprising: receiving asession invitation at a first user access server from a sessioninitiating user, the invitation identifying as a potential participantat least one user group which is owned by a second user access server;sending an invitation to the second user access server, the invitationincluding an identification of said user group; at said second useraccess server, resolving the group identification into a set of groupmember identities; sending a response containing said group memberidentities to said first user access server; and at said first useraccess server, sending an invitation to at least some of the groupmembers identified in said response.
 2. The method according to claim 1,wherein said session is a push-to-talk session and said user accessservers are push-to-talk servers and said users are push-to-talkclients, said first user access server acting as a controllingpush-to-talk server, while the second user access server acts as aparticipating push-to-talk server.
 3. The method according to claim 1,further comprising, at the second user access server, using apre-defined policy to authorize invitation of the identified group tothe session.
 4. The method according to claim 1, further comprising, atthe second user access server, using a pre-defined policy to authorizethe requesting user to invite the identified group to the session. 5.The method according to claim 4, wherein said pre-defined policyrequires that the requesting user be a member of the pre-defined groupin order to proceed.
 6. The method according to claim 1, wherein thestep of sending the invitation from the first access server to at leastsome of the identified group members includes sending invites toselected group members according to a pre-defined policy.
 7. The methodaccording to claim 6, wherein the pre-defined policy prevents thesending of invitations to group members which are themselves groupidentifications.
 8. The method according to claim 6, wherein thepre-defined policy allows the sending of invitations to group memberswhich are themselves group identifications up to a predefined number ofnested levels.
 9. A user access server for use in an IP MultimediaSubsystem, the server comprising: means for receiving a sessioninvitation from a session initiating user, the invitation identifying asa potential participant at least one user group which is owned by asecond user access server; means for sending an invitation to the seconduser access server, the invitation including an identification of saiduser group; means for receiving from said second user access server aresponse containing group member identities resolved by the secondaccess server from said group identification; and means for sending aninvitation to at least some of the group members identified in saidresponse.
 10. A user access server for use in an IP MultimediaSubsystem, the server comprising: means for receiving from another useraccess server an invitation including an identification of a user groupowned by the receiving server; means for resolving the groupidentification into a set of group member identities; and means forsending a response containing said group member identities to said firstuser access server.